Should we include a case where perhaps one of the controllers has not been upgraded?

What would we show in that case?

Was just chatting with Simon about it and we'll switch to using the version in Namespace rather than this one

@foot @bigkevmcd Just to sum up as we are discussing to show both the version in the controller and the one in the namespace. How do we want this to look like?

So the base the user stories we want to cover:

• What version of flux do is installed
• What components of flux are installed

Additional questions we can answer on top (but this is kind of getting away from the dev user stories?)

1. What namespace is flux installed into (99% flux-system)
2. Is the flux install broken (mismatches in components versions)

For 1, we add the namespace column.

For 2, we could

• show every component's reported flux version by making each component a column (perhaps a bit info overload)
• show the versions in a tooltip on hover of the components list.
• something a bit more "clever" like, if component.flux-version !== ns.flux-version, show version in yellow with a warning next to the component.

Tooltip could work here?

So the base the user stories we want to cover:

• What version of flux do is installed
• What components of flux are installed

Additional questions we can answer on top (but this is kind of getting away from the dev user stories?)

1. What namespace is flux installed into (99% flux-system)
2. Is the flux install broken (mismatches in components versions)

I agree that we need to not get away from dev user stories.

My original thinking

1. It's useful broadly in terms of the Flux experience within Backstage
2. If something isn't quite working, it might be useful to see the version of Flux on the cluster so that you know what's running to try and figure out why your Flux components might not be succeeding.

I was thinking about the case where a field had changed (or didn't exist) in a Flux resource that we show the status of, it would be useful to know what version is running in "that cluster" to understand why?

But it's easy to then think, well, you need to click through to Weave GitOps to view the resources in more detail, so maybe we don't need this at all, because you can go to Weave GitOps for this level of debugging information?

For 1, we add the namespace column.

For 2, we could

• show every component's reported flux version by making each component a column (perhaps a bit info overload)

This would serve two roles, it would provide the versions, but it would also highlight missing controllers across clusters.

As long as it scaled with the controllers (let's not add all controllers to the table unless we discover all of them).

• show the versions in a tooltip on hover of the components list.
• something a bit more "clever" like, if component.flux-version !== ns.flux-version, show version in yellow with a warning next to the component.

I like this idea, this feels really useful with low screen-overhead.

Tooltip could work here?

Yes, for versions of the controller, and I like the version colouration idea above too!

I'd also be happy for this to be fixed up and landed, and we can always choose to make it better.